feat(codegen): auto-generate docs with dot-notation, clean types, --no-tty, and backend-default awareness

Summary

Updates the codegen docs generators so that generated agent skills, READMEs, and MCP tool definitions automatically reflect INPUT_OBJECT dot-notation flattening, clean scalar type names, --no-tty non-interactive mode, and correct required/optional status based on backend-provided defaults — no hand-editing of skill files needed.

Core change: Added flattenArgs(args, registry?) and resolveInputFields() helpers in docs-utils.ts that resolve INPUT_OBJECT types from the TypeRegistry (since CleanTypeRef intentionally omits inputFields to avoid circular references). All 8 docs generator functions (generateReadme, generateAgentsDocs, getCliMcpTools, generateSkills + their multi-target variants) now accept an optional TypeRegistry and pass it through to flattenArgs.

Before: csdk sign-in --input <value>
After: csdk sign-in --input.clientMutationId <value> --input.email <value> --input.password <value> --input.rememberMe <value> ...

Also adds --no-tty documentation sections to all generated READMEs and SKILL.md files.

Updates since last revision

Backend-default awareness in docs: Fields with backend-provided defaults (NON_NULL in GraphQL schema but nullable in the CREATE input type, or having an explicit defaultValue from introspection) are now correctly shown as optional rather than required in all generated docs. This is accomplished by exporting getFieldsWithDefaults() and resolveInnerInputType() from table-command-generator.ts and calling them in all 8 doc generator functions.

Applied across all doc types:

• README: Separate Required create fields and Optional create fields (backend defaults) sections
• AGENTS.md: Bracket notation [--field <value>] for optional fields + (optional, has backend default) labels on editable field lists
• MCP tools: required array in inputSchema only includes truly required fields; omitted entirely when all fields have defaults
• Skills: Bracket notation [--field <value>] in both usage and example sections

Example (view-grant create):

• Before: csdk view-grant create --databaseId <value> --viewId <value> --granteeName <value> --privilege <value> --withGrantOption <value> --isGrant <value>
• After: csdk view-grant create --viewId <value> --granteeName <value> --privilege <value> [--databaseId <value>] [--withGrantOption <value>] [--isGrant <value>]

Clean type names: Added cleanTypeName() helper that strips the ConstructiveInternalType prefix from custom scalar types in generated docs. Applied across all 11 occurrences of f.type.gqlType in docs-generator.ts (README tables, AGENTS.md field lists, MCP tool props) and in getScalarTypeName() for flattened args.

• 6 unique affected types: Email, Hostname, Image, Url, Origin, Attachment
• 28 total occurrences cleaned across generated output
• Before: ConstructiveInternalTypeEmail — After: Email

Files changed (source):

• docs-utils.ts — new flattenArgs(), flattenedArgsToFlags(), resolveInputFields(), cleanTypeName() helpers
• docs-generator.ts — all 8 generators accept TypeRegistry, use flattened args, clean type names, compute required/optional fields, add --no-tty docs
• table-command-generator.ts — exported getFieldsWithDefaults() and resolveInnerInputType()
• generate.ts — threads customOperations.typeRegistry to CLI docs calls; merges registries for multi-target
• 5 test snapshots updated
• ~155 regenerated skill reference files + READMEs

Review & Testing Checklist for Human

• Required/optional field classification: Spot-check a few tables (e.g. view-grant, user, database) to confirm that fields marked as optional truly have backend defaults and won't cause create failures if omitted. The heuristic treats all nullable fields in the inner input type as having defaults — verify this matches PostGraphile's actual behavior.
• NON_NULL heuristic correctness: getFieldsWithDefaults() marks any field with type.kind !== 'NON_NULL' as having a default. Verify that PostGraphile never uses nullable input fields for truly-required-without-defaults fields that would fail at runtime if omitted.
• clientMutationId noise: Every flattened INPUT_OBJECT now shows --input.clientMutationId as the first flag in usage/examples. This is technically correct but clutters docs since most users never pass it. Consider whether clientMutationId should be filtered out in flattenArgs().
• cleanTypeName prefix stripping: The function strips the exact string "ConstructiveInternalType" — verify no type names exist where this prefix is legitimate and should be preserved. Grep generated output for any unexpected type name results.
• Long usage lines in skill references: Commands with many input fields (e.g. set-and-commit with 8 fields) produce very long single-line usage strings. Check if this is acceptable for agent consumption.
• Run pnpm run generate in constructive-cli after merge to confirm the regenerated output matches expectations against the latest schema.

Notes

• Requested by @pyramation
• Devin Session
• This PR does NOT change any CLI runtime behavior — only the generated documentation (skills, READMEs, AGENTS.md, MCP tools).
• All 301 tests pass, 5 snapshots updated. Note: test snapshots don't exercise ConstructiveInternalType names or complex backend defaults (example schema doesn't use custom scalars or many nullable create fields), so the new behaviors are verified primarily by inspecting regenerated output.
• Cannot test end-to-end: Generated docs look correct but the actual CLI behavior with flattened flags (--input.email etc.), clean type names, and correct required/optional handling requires a running backend to verify. CI checks compile/lint only.